A run-time system (also called runtime system or just runtime) is a software component designed to support the execution of computer programs written in some computer language. The run-time system contains implementations of basic low-level commands and may also implement higher-level commands and may support type checking, debugging, and even code generation and optimization.
Some services of the run-time system are accessible to the programmer through an application programming interface, but other services (such as task scheduling and resource management) may be inaccessible.
A run-time system relieves programmers from the burden of writing code for mundane tasks such as drawing text on the screen or making an Internet connection. It also provides an abstraction layer that hides the complexity or variations in the services offered by the operating system. In the limit, the run-time system may be a P-code machine or virtual machine, that hides even the processor's instruction set. This is the approach followed by many interpreted languages such as AWK, and some languages like Java that are meant to be compiled into some machine-independent pseudocode (bytecode). This arrangement greatly simplifies the task of language implementation and its adaptation to different machines, and allows sophisticated language features such as reflection. It also allows the same program to be executed on any machine without recompiling, a feature that has become very important since the diffusion of the World Wide Web.
In vFortran, the run-time system consisted basically of the standard library subroutines, such as SQRT() (square root) and the routines that implemented the FORMAT specs.
Notable early examples of run-time systems are the interpreters for BASIC and Lisp. The latter included also a garbage collector. Forth is an early example of a language that was designed to be compiled into pseudocode; its run-time system was a virtual machine that interpreted that pseudocode. Another popular, if theoretical, example is Donald Knuth's MIX computer.
In C and later languages that supported dynamic memory allocation, the runtime also included a library that managed the program's memory pool.
In the object-oriented programming languages, the run-time system was often responsible also for dynamic type checking and resolving method references.
An early example of run-time system is that included in the RSTS operating system. The "run-time system" (RTS) was the resident code (that is, code always in memory) which was mapped into the high end of the address space of a process, and could be called to provide services to a program, or used as the command line interpreter (CLI) user interface. The term in RSTS for a command line interpreter was keyboard monitor (KBM). This term should not be confused with the similar term keystroke logging.
RSTS did not itself define any standard filename extension for an executable program file; instead, each installed RTS defined its own extension, and the appropriate RTS was loaded depending on the actual name of the program file. If the user issued a command to run a program without specifying the extension, then the system went through all installed RTSs, trying each corresponding extension in turn until it found the name of an existing program file.
The responsibility for loading and executing the program was left to the run-time system, so users could run interpreted programs just as easily as those compiled into actual machine code, if the interpreter was appropriately implemented as a run-time system. The standard BASIC-PLUS RTS provided a compiler, interpreter and KBM all packed into just 32KiB of code. And indeed many of the standard system utility programs (including privileged ones like LOGIN and LOGOUT) were written in BASIC-PLUS.
Other RTSs provided some emulation facilities, allowing simple programs written for the RT-11 and RSX-11 operating systems to run under RSTS. An interesting note is that not all RTS's were designed as KBMs, however almost all KBMs were implemented as RTSes.
Under RSTS, the Text Editor and Corrector (TECO) was implemented as an RTS, though its KBM function was a stub which loaded a program with a predefined name which had to be provided by the user. This allowed the user to implement their own KBM.
Even the Space Invaders video arcade game was eventually implemented as a multi-user RTS (driving VT52 video terminals).